페이지 계산 시 PageLogic.calculate가 최신 Page를 읽고 PageMeta.upsert를 수행한다.

링크(CalculatedLink)는 다른 페이지로 가는 것만 기록한다. 앵커([#x])와 질의([?x])는 그 페이지 자신을 가리키므로 뺀다(InterpreterWiki.extractLinkMarkup). 질의는 2026-10-03 까지 기록돼서, ?q=10 이라는 페이지로 가는 링크가 생겼고 인접 페이지 그래프가 그 링크 목록을 /api/links 에 물어 404 를 받았다. #!WikiSyntaxPreview 블록은 미리보기 쪽이 그리는 링크만 센다 — 뒤에 이름을 적은 인터프리터로 읽는다는 뜻이고, #!WikiSyntaxPreview Vim javascript 처럼 코드를 보여 주는 블록에는 링크가 없다. 같은 날까지는 언제나 위키 문법으로 읽어서, InterpreterVim 의 JavaScript 예시가 링크 하나를 만들고 있었다.

#! 줄이 없는 [[[ ]]] 블록은 텍스트로 그려지므로 링크도 없다. 블록을 읽는 쪽 — 그리기, 감싸는 div 의 class, 링크, schema.org — 은 모두 ExtractConvertInjectInterpreter.withInterpreter 를 거쳐 같은 것으로 읽는다. 2026-10-03 까지는 그리기만 텍스트로 읽고 링크 계산은 위키 문법으로 읽어서, 사용법 줄의 [options...] 나 정규식의 [a-z0-9] 가 그 이름의 페이지로 가는 링크가 됐다(aha00a.com 에서 41페이지, 링크 248개). 인접 페이지 그래프는 그 이름들을 /api/links 에 물었고, 감싸는 div 의 class 는 Wiki 였다.

계산은 저장할 때, PageMeta 가 없는 페이지를 스케줄러가 찾았을 때, 그리고 페이지 보기 열 번에 한 번 돈다(Wiki.scala). 그래서 읽는 요청이 늘 가까이 있다. 보기에서 온 계산은 2026-10-12 부터 그 페이지가 최신 리비전으로 하루 안에 계산돼 있으면 건너뛴다(PageLogic.isCalculatedRecently). 계산이 만드는 것 대부분 — 설명, 대표 이미지, 단어 빈도, 링크, schema.org — 은 그 페이지 자신의 글에서 나오고, 글은 편집으로만 바뀌며 편집은 저마다 계산을 부른다. 보기로만 따라오는 것은 유사도다: 유사도 행은 계산한 페이지 쪽에서만 쓰므로, 다른 페이지의 편집이 이 페이지의 비슷한 페이지 목록에 닿는 것은 이 페이지가 다시 계산될 때다. 그래서 그 목록은 이제 최대 하루 늦을 수 있고, 계산 방식을 바꾼 배포가 편집 없는 페이지에 닿는 것도 그 페이지가 보인 뒤 하루 안이다. 하루로 고른 이유와 잰 값은 PageLogic.ViewRecalculationInterval 의 주석. 단어 빈도(CalculatedTermFrequency.replace)와 유사도(CalculatedCosineSimilarity.recalc)는 지우고 다시 넣는 일이라 각각 한 트랜잭션으로 묶는다. 2026-10-02 까지는 따로 커밋해서, 그 사이에 MacroSimilarPages 를 그린 독자는 공통 단어나 유사 페이지가 일부 빠진 목록을 봤다 — 배포 대조에서 같은 코드의 두 인스턴스가 다른 단어 목록을 낸 것이 그것이었다. 두 인스턴스가 겹치는 행을 동시에 다시 계산하면 교착(deadlock)이 날 수 있다 — 서로 비슷한 두 페이지는 같은 유사도 행을 쓴다. 그래서 두 곳 다 LocalTransaction.retryingDeadlock 으로, 교착의 희생자가 되면 세 번까지 다시 돈다. 파생 데이터라 두 번 돌아도 결과가 같다.

처음에는 재시도 없이 «그 계산이 버려질 뿐이고 다음 계산이 다시 쓴다» 고 적었는데 틀렸다. 트랜잭션을 넣기 전 53일치 로그에 교착은 0건이었고, 넣은 지 한 시간 안에 한 건이 났다(2026-10-03 05:35, 배포 대조가 모든 페이지를 여는 동안). 예외는 유사도에서 났지만 계산이 거기서 멈추므로 그 뒤의 링크·schema 계산까지 같이 빠졌고, 액터의 ERROR 로 남았다.

2026-10-03 배포에서 확인했다. 한 대만 새 코드였을 때는 옛 코드 쪽이 Dev Database 를 다시 계산하는 3초 동안 새 쪽이 빈 단어 목록을 그렸다. 두 대를 다 올린 뒤에는 그 페이지를 150번 그리는 동안 재계산이 열여섯 번 넘게 돌았는데, 빈 목록은 한 번도 없었다. 그때는 교착 로그도 없었지만, 50분 뒤 다음 배포의 대조 중에 위의 한 건이 났다.

대표 이미지는 다음 순서로 선택한다.

• #!Schema의 image 또는 logo
• 업로드된 Attachment
• [[Image(...)]]
• [[Attachment(...)]]

3·4 의 매크로는 페이지가 실제로 실행하는 것만 센다 — 코드 표기(백틱) 안의 것, 그리고 렌더러가 본문을 손대지 않는 블록 안의 것은 건너뛴다. 본문을 그대로 보여 주는 #!Vim·#!Text·#!WikiSyntaxPreview 와, 원문을 그대로 넘기는 #!Kanban·#!Gantt·#!Mermaid·#!Math·#!Html 이다(PageLogic.markupOnly, 렌더러가 백틱을 그대로 두는 블록과 같은 목록). 칸반 카드에 올린 첨부는 2 의 업로드된 Attachment 로 잡힌다. 2026-10-03 까지는 원문 전체에서 찾아서, 위 목록을 백틱으로 적은 이 페이지의 이미지가 ... 이었고 이 페이지를 보여 주는 그래프마다 /... 을 요청해 404 를 받았다. InterpreterKanban 은 예시 카드의 [[Attachment(path/to/file.png)]] 가 이미지가 되어 역시 404 였다.

이미지가 없으면 NULL로 저장한다. API(pagePreview, links)는 빈 문자열을 돌려주고, 화면 쪽 스크립트가 attachmentFallback.svg 를 대신 쓴다. og:image·twitter:image 는 대표 이미지와 무관하게 언제나 attachmentFallback.svg 다(_baseSkeleton.scala.html) — PageMeta.image 는 뷰로 넘어가지 않아, 대표 이미지가 있어도 소셜 미리보기에는 쓰이지 않는다.